One of the reasons the World Wide Web (or Web) is so popular is the ability of users to publish and interact with rich content. Examples of rich content include Web sites with both foreground and background images, multiple colors, interactive controls, fonts, audio clips, code modules, and animation. Users generally interact with rich content using Web browsers. Web browsers display the rich content from Web sites to the user and permit the user to interact with the rich content using input devices such as a keyboard or a mouse. Creating and editing rich content is relatively easy. Many software applications generate professional looking rich content. These applications enable a user to create rich content including images, fonts, sounds, animation, and user-interactive controls.
Because of a Web browser's ability to display rich content, some Web browsers have been modularized so that they can be embedded in display windows of other applications. There are at least two benefits realized by embedding a Web browser in a display window: first, an application developer is relieved of crafting a display mechanism in the application; and second, as described above, the content is full featured, and easy to generate and modify.
Web browsers generally display ‘standard’ rich content: rich content containing those features defined according to some standard. HTML (hypertext markup language), XHTML (extensible hypertext markup language), and XML (extensible markup language) are examples of rich content formats that have been “standardized” by the World Wide Web Consortium (the W3C), a widely recognized standardization body for developing interoperable technologies for information exchange, commerce, and communication on the Web. Before they become standards according to the W3C, or some other standardization body, proprietary or specialized features developed within the foregoing (and other) formats are deployed on Web sites. Some of these new features may never be standardized. For these cases, most Web browsers have been developed to accept plug-in modules. In a general, plug-in modules are software extensions to an application, specifically in this case, a Web browser. A user will typically install a plug-in module into a specific directory location associated with a Web browser. This will typically be a known location that the Web browser searches when starting up. If the plug-in module is properly located, the Web browser will properly interact with the plug-in module to extend, or enhance, the Web browser's abilities, including displaying nonstandard, proprietary features stored in a Web file.
Combining these features—Web browsers adapted to function as display modules having plug-in extensibility—creates an extremely adaptable and powerful display mechanism. Unfortunately, while display of rich content through a browser-embedded window is a relatively simple process, interaction with embedded controls in rich content is problematic. This difficulty arises from the structure of the browser-embedded display: an interactive control in a browser-embedded window will send control messages, also referred to as callbacks, from the embedded controls to the application that “owns” the browser-embedded window, and not the plug-in module from whence the content originated. Currently, to handle this situation, each plug-in module must arrange with each host application some way for receiving callbacks from controls embedded in the rich content from the host application. No standardized mechanism exists to accomplish the transfer of such control messages.
Another problem facing plug-in module developers arises from the installation location of a host application. With few exceptions, a user may install a host application in any directory location. As previously mentioned, in order to properly function, plug-in modules and associated files must be installed in certain locations in relation to the host application. For example, many host applications require that plug-ins be installed in a specific subdirectory, and associated files, such as images, rich content, or plug-in related data, be installed in other known locations. These location requirements create difficulty for rich content files containing references to other related plug-in files. Currently, references to other related files in the rich content must be modified when installing a plug-in module, as it is only during installation that the precise locations of these related files can be determined. Later updating of these files presents the same problem: the need to modify the plug-in related files according to the installation directory of the host application.
What is needed is a system and method for enabling plug-in modules to display rich content within a browser-enabled window and receive callbacks from controls embedded within the rich content in a standardized manner. The system and method should provide a way to reference related files without explicit modifications to the related files for each host installation. The present invention is directed to fulfilling this need.